A user of a telecommunications network accesses this network by way of an access network. Several types of access are available. These include fixed accesses, based for example on x-DSL (Digital Subscriber Line) technology, and mobile accesses based on UMTS (Universal Mobile Telecommunication System), WIFI or WImax technologies.
Certain access networks of IP (Internet Protocol) packet type possess so-called AAA (Authentication, Authorization, Accounting) authentication infrastructures, which carry out the authentication of the users, manage the authorization of access to the requested services and perform the accounting for billing the user for the service.
In a conventional manner, the AAA architecture relies on the following principles:
The user's terminal hooks up to the access network via a network access point.
In the access network, a network access server is responsible for controlling access to the IP transport core network, which itself provides services for accessing other IP networks such as the Internet or else a private IP network, such as a companies network for example.
In this context, the role of the network access server is to authenticate and to authorize the terminal to access the IP core network. To carry out these functions, this access server dispatches, on receipt of a request issued by the terminal, a request for access to an authentication server in charge of verifying the authentication parameters provided by the terminal. Once authentication has been successful, access to the network services is authorized as a function of the rights of access associated with the user of the terminal.
Today, the AAA architecture is also implemented for the authentication of a user already connected to an operator's IP transport core network, but who desires to access a service provided by an application system of this network. For example, to access an IP mobility service which will allow him to change type of access in the course of an application session, the user must authenticate himself a second time with the AAA architecture.
The authentication and authorization data are grouped together in what is called a user data profile. This profile is hosted either in the authentication server receiving the access request, or in another authentication server. In this case, the access request is transmitted to the latter and it is this server which will ensure authentication of the terminal.
Once the authentication and authorization procedures have been carried out, the network access server is in charge of generating accounting messages containing the information related to the events associated with the connection in progress (start of session, end of session, volume of data transmitted, etc.). These messages are dispatched to a specialized server which will be in charge of generating billing invoices as a function of the accounting information received. This server may be co-located with the authentication server or be an independent server.
The servers carrying out the Authentication, Authorization and/or Accounting functions are generically called “AAA servers”. The network access servers which are the “clients” of these AAA servers are called “AAA clients”.
The so-called AAA protocols are the protocols used on the interfaces between AAA client and AAA server or between AAA servers. Specified at the IETF, the one most used at present is the RADIUS protocol (IETF RFC 2865). Since 2002, the IETF has defined a new protocol called Diameter (IETF RFC 3588), the successor to RADIUS, making it possible to respond to the new functional requirements and constraints prompted by the emergence of new types of access networks and of new network services such as IP mobility management for example.
The AAA architecture will now be described in conjunction with FIG. 1.
A user terminal UE 10 (User Equipment), which desires to access an IP data network 3 such as the Internet, is considered. It connects initially to the operator's telecommunications network 1 through an access management server (Network Access Server) NAS1 110 of an access network 20. At the level of the access network, one also speaks of access point (AP). This may be fixed access of x-DSL type or mobile access of WIFI type, for example. This connection requires a first authentication which is requested of an authentication server AAA1 210 of the network 1 by the access management server NAS1 110. The authentication server AAA1 210 recovers a profile of the user from a database DB 400 which may be local or centralized.
Once this first authentication has been successful, the terminal issues a request for access to the IP network (or service) 3 through an access management server for this service or NAS2 120. For this purpose, it uses a protocol making it possible to establish an IP connection.
Several protocols may be used as a function of the type of access network and of the type of network to which access is desired. Cited by way of example are the PPP protocol (Point To Point Protocol, described in the IETF document RFC 1661) for fixed accesses to the Internet with the aid of modem of RTC type, the IEEE protocol 802.1X (described in the IEEE document standard 802.1X-2001 “Port-Based network Access Control”) for Wifi accesses or else the IKEv2 protocol (Internet Key Exchange V2, RFC 4306) for setting up IPsec security association for accesses of VPN (Virtual Private Network) or I-WLAN type.
The server for managing access to the service NAS2 issues a request for authentication of the user through an authentication server AAA2 120. It is understood that this authentication server may be different from that which carried out the first authentication of the user.
The AAA architecture in fact affords the possibility of distributing over a given territory several network access servers charged with controlling access to the resources. When several AAA servers are deployed in the network, each server can have its own user database or all the servers are connected to a centralized database. The centralized architecture is the one found in particular in mobile networks. The use of a centralized base allows the user to be able to move to any network access point while being certain of being able to be authenticated and authorized to access its services.
When, as in the example of FIG. 1, the user desires to access a service which requires two successive authentications, it is desirable to exploit the first authentication so as to simplify the second. In this regard, there exist moreover mechanisms of reauthentication at the local level. These same mechanisms could be reused or adapted within the framework of successive authentications by one and the same operator. For example, the ERP protocol (EAP Extension for EAP Re-authentication Protocol, defined at the IETF in RFC 5296) makes it possible to reuse the cryptographic material arising from a first authentication carried out with the EAP protocol (Extensible Authentication Protocol, defined at the IETF in RFC 3748). This makes it possible to reduce the number of signaling messages exchanged in the network as well as the calculation times on the equipment concerned. This being particularly true in the case where the terminal is in a visited network and the cryptographic material is held in the local network.
However, such mechanisms risk being inoperative when the user, already authenticated a first time by the network, does not address himself to the same server NAS1 for managing access to the network during a second authentication. Such a situation arises in particular in the previous example when access to the access network and access to the Internet network are managed by different access management servers. It also arises when the user is roaming and has changed access network since the first authentication in the access network. Such a case will now be presented in conjunction with FIG. 2.
The terminal UE 10 has connected to the access network 21, for example a mobile access network of Wifi type. An access management server NAS1 and an authentication server AAA1 have taken charge of the appropriate connection and authentication procedures. It is assumed that the user moves and changes point of access to the access network 21. He must reconnect to the access network in the course of a so-called handover procedure (transfer), through a second access management server for the network NAS2 120.
The IETF document RFC 4282 by Aboba et al, entitled “The Network Access Identifier”, is considered, said document teaching the use of an access network identifier (Network Access Identifier or NAI) submitted by the user to the access management server NAS1, NAS2 during his requests for access to a service. This identifier indicates the domain of the operator with which the user has taken out a subscription. On receipt of this identifier, the server for managing access to the service makes a DNS request to recover the address of the AAA server or servers corresponding to this domain. A problem arises when, as in the example of FIG. 2, several AAA servers have been deployed for this domain, this possibly occurring for load sharing and security reasons.
Indeed, in this case, knowledge of the identifier NAI does not allow the access management server to identify which local AAA server from among the AAA servers deployed in the domain is in charge of this user.
In conjunction with FIG. 3, the case is now considered where the user is additionally in a “roaming” situation, that is to say he accesses a service to which he has subscribed through his operator via the network 2 of a third party operator. An access management server NAS1′ and a proxy authentication server pAAA1 of the visited network 2 take charge of the appropriate connection and authentication procedures. The server for managing access to the local service NAS1′ makes, with this aim, a DNS request to recover the address of a local proxy AAA server pAAA1. The server pAAA1 thereafter contacts an AAA server of the network 1, termed the attachment or “home” network of the user, which undertakes the authentication. The authentication server AAA1 of the network 1 has previously recovered a profile of the user from the database DB 400 of the network 1.
It is thereafter assumed that, as in the previous example, the user moves and changes point of access to the access network 21′. He must reconnect to the network for access to the visited network 2 in the course of a so-called handover procedure (transfer), through a second server NAS2′ for managing access to the network. This second management server NAS2′ contacts a proxy authentication server pAAA2 by default, which addresses itself in its turn to an AAA server AAA2 of the home network 1.
In this regard, the 3GPP standard TS 23.402 describes a solution for the server AAA2 to recover an identifier of the server AAA1 which has undertaken a first authentication of the user through the database DB 400, in the particular case where the latter was implemented in an HSS (Home Subscriber Service) server. The server AAA2 can then behave in two ways:                either it behaves as proxy and transmits the request for authentication of the roaming user to the server AAA1 of the network 1;        or it dispatches to the proxy AAA server pAAA2 of the visited domain 2 the identity of the server AAA1 so that it recovers the user's profile from it.        
It is understood that none of these options offers the management server NAS2′ the possibility of recovering the identity of the proxy server pAAA1 which had been used during the first authentication. Thus, if the proxy server pAAA1 possessed additional cryptographic material allowing fast reauthentication of the user's terminal, it cannot be utilized.
It should be noted that the standard 33.402 describes this solution with the aim of avoiding a new transmission of the user's profile to another AAA server AAA2, not with that of optimizing the process for reauthenticating the user in a roaming situation.